Size Report

Bundles

Usages

Open in Stackblitz

npm i https://pkg.pr.new/@vue/compiler-core@12733

npm i https://pkg.pr.new/@vue/compiler-sfc@12733

npm i https://pkg.pr.new/@vue/compiler-dom@12733

npm i https://pkg.pr.new/@vue/compiler-ssr@12733

npm i https://pkg.pr.new/@vue/runtime-core@12733

npm i https://pkg.pr.new/@vue/runtime-dom@12733

npm i https://pkg.pr.new/@vue/reactivity@12733

npm i https://pkg.pr.new/@vue/server-renderer@12733

npm i https://pkg.pr.new/@vue/shared@12733

npm i https://pkg.pr.new/vue@12733

npm i https://pkg.pr.new/@vue/compat@12733

commit: 2336e2a

I'm not sure whether it would be considered a problem, but this change would also impact $refs.

I'm not sure whether it would be considered a problem, but this change would also impact $refs.

Thanks for your review. Perhaps this cannot be regarded as a problem, because this kind of behavior already exists in PROD.

• open Playground - main branch
• click the button twice, see console.log
• i.refs['elements2'] is a Proxy array in PROD

I would be nervous about drawing any conclusions based on that example. getCurrentInstance() is undocumented, so to hit that edge case using documented APIs you'd need to mix <script setup> and the Options API. Not only is it inconsistent between DEV and PROD, it also behaves differently depending on whether you use ref() or ref([]):

• Playground

It strikes me as an unintentional edge case, rather than something we should be using as precedent.

I'm not entirely clear why $refs isn't reactive, but personally I think it's a decision that should be revisited. That might also allow the implementation of useTemplateRef to be simplified too.

But, given $refs currently isn't reactive, I'd be hesitant to introduce partial reactivity in just the v-for case unless we're planning to move towards full reactivity in future.